1.Do you know that there is a deprecated package in your codebase?
 1.Yes.
 2.No.
 3.No package is deprecated.

2.How often do you check for deprecated dependencies in your projects?
 1.Very often.
 2.Occasionally.
 3.Rarely.
 4.Never.
 5.Conditional.
 6.Automatically.

3.How do you check whether one package is deprecated or not?
 1.Check the homepage for a deprecation announcement.
 2.Check the issue tracker to find any deprecation announcement in issues.
 3.Subscribe to the RSS feed of the project if available.
 4.Receive emails from the developer or package manager.
 5.Github bot.
 6.By chance.
 7.Deprecation warning from code (include installation).
 8.Via package’s test.
 9.Regression test.
 10.Check activity events.
 11.Github dependency tracker.
 12.snyk.io.
 13.Poetry show —outdated.
 14.An automatic checker.
 15.Package manager.

4.Do you want to be notified when there are deprecated dependencies in your codebase by the package manager (i.e., PyPI) or the package owner? 
 1.Yes.
 2.No.
 3.Maybe.

5.How would you expect to be notified about the deprecation of a package?
 1.An announcement on the homepage.
 2.A warning displayed during package installation.
 3.A warning displayed when using the package.
 4.An Email containing the deprecation announcement.
 5.A pip flag.
 6.Warning from Github.

6.What content do you expect to be included in the deprecation announcement?
 1.Reasons for deprecation.
 2.Alternative solutions.
 3.A severity report.
 4.Nothing.
 5.Whether the maintainership can be passed.

7.Is it more difficult to make the decision without an explicit deprecation announcement regarding whether to adopt, remove, or take other actions on an inactively maintained package that hasn't been updated for a long time？
 1.Yes.
 2.No.
 3.Not sure.

8.In what situation will you take actions on deprecated packages?
 1.There are no more new features.
 2.There are no future bug patches supported.
 3.If the deprecated package includes dependencies that are reported as vulnerable in the future and the  deprecated package does not update  them to a vulnerability-free version.
 4.There are already existing vulnerabilities or bugs.
 5.There are better alternatives available.
 6.I don’t want to take any action.
 7.Not compatible with other new dependencies or up to date environment.

9.What actions will you take on the deprecated dependency?
 1.Fork and develop a new version.
 2.Seek another solution.
 3.Remove the dependency.
 4.I don’t want to take any action.
 5.Only fork and maintain the part they need.

10.Are there any challenges when taking action on the deprecated packages?
 1.Not sure how to take action.
 2.Lack of time and resources.
 3.Potentially no alternatives exists.
 4.Not aware.
 5.Lack of support documents.

11.What kind of support do you expect from developers and package managers?
 1.Migration guidelines.
 2.Guidelines for taking over the package and continuing its development.
 3.Notification.
 4.Source code.

12.If you have any additional thoughts on the challenges related to unmaintained packages that you would like to share, or if you have any comments about the survey, please feel free to share them with us in this question.
 1.Poor backward compatibility.
 2.People can fork.
 3.Dependabot doesn’t suitable for notifying deprecation.
 4.Github and PyPI should post the download numbers.
 5.More categories are needed, or spectrum.
 6.Ambiguity making the justification even harder, struggle to identify.
 7.Reducing dependencies.
 8.Truck factor.
 9.No alternative solution.
 10.Lack of resources and interest.
 11.Uncertain about usage.
 12.Develop an automated checking service.
 13.Already forked.
 14.The bar of forking is high.
 15.Addressing the issues takes a long time.
 16.Warning would be great.
 17.Severity report, the severity depends on different types of software.